1. Field of the Invention
The present invention pertains to the Internet. More particularly, this invention relates to intelligently classifying and handling user requests in a data service system.
2. Description of the Related Art
With the rapid growth of the Internet, more and more business and residential users are beginning to rely on the Internet for their mainstream and mission-critical activities. As is known, the Internet typically refers to a number of data service systems connected together via a high speed interconnect network (see FIG. 1). Each data service system (e.g., the data service system 13 or 20 in FIG. 1) typically includes Internet server applications that host contents for various customers. Remote client systems (e.g., the client systems 11a–11n in FIG. 1) may be connected to a data service system (e.g., the data service system 20 in FIG. 1) via an interconnect network. Each client system is equipped with a web browser (or other software such as an e-mail software) that allows its user (i.e., a person) to access the contents and/or applications hosted in various data service systems through the corresponding client system.
Popular Internet applications include World Wide Web (WWW), E-mail, news, and FTP applications. All of these applications follow the client-server model and rely on the Transmission Control Protocol (TCP) for reliable delivery of information/applications between severs and client systems. These applications can also be referred to as server applications. A user can access a server application (e.g., web server) by generating at least one request from a corresponding client system to the corresponding server application. The server application then services the request. A server application can be accessed by multiple client systems at the same time. The server application typically serves the user requests in the first-in-first-out (FIFO) fashion.
One problem of the above-identified prior art server application is that it does not have protection mechanism against excessive load conditions. Unbearably long delays may occur when the total number of user requests received by the server application at one time greatly exceeds the total number of access requests permitted by the server application (i.e., the entire system is overloaded).
Another problem is that the server application does not provide predictable performance or predictable response to its customers that host their content/service sites in the server application. This means that the prior art server application does not provide features like performance stability over a range of client demands, non-interference performance among co-hosted content sites, targeted performance, and overload protection for the hosted content sites.
To overcome these problems, prior proposals have been made to add quality-of-service (QoS) middleware in the server application. The QoS middleware classifies requests into different classes. For example, the QoS middleware classifies a request as an existing session request if the incoming request is part of an existing session. If the incoming request is not part of an existing session, then the middleware can classify the request as a new session request. Furthermore, the above described prior solution can also be realized by hardware load balancers (e.g., products from Foundry Networks, Inc. Alteon Systems, Inc.) can also be employed.
Disadvantages are, however, still associated with this prior approach. One disadvantage is that the classification is very inflexible and is done in a rather mechanical way. For example, if used for on-line transactions, the above-mentioned prior art middleware does not take into account the type of transaction (e.g., the amount of money involved) of each request. As is known, a one-million-dollar transaction should be treated with a higher priority than a ten-thousand dollar transaction. The prior art middleware provides the same treatment to all requests within the same class, regardless of the transaction type of each request. If the middleware needs to send a request from the existing session class to the server application, the middleware will only pick one request from the existing session queue based on the FIFO order. Similarly, if the middleware needs to send a request from the new session class to the server application, the middleware will only pick one request from the corresponding queue based on the FIFO order.